Subject: review of draft-ietf-dlswmib-mib-07.txt (fwd)

From: Shannon Nix <[email-masked]>
Date: Mon, 8 Apr 1996 08:05:13 -0400 (EDT)

Hello DLSw Mibbers,

Kaj Tesink of the IETF NM Directorate has completed the review
of the DLSw MIB (comments attached). Some of these are simply
editorial and can be easily dispatched.

Dave/Peter, could you compile a list of the items below which need
further discussion.  Then I will try to organize an appropriate forum
for said discussion.

Of course, comments on all items are welcome,
Shannon

Forwarded message:
> From [email-masked] Fri Apr  5 09:24:37 1996
> Date: Fri, 5 Apr 96 09:30:26 EST
> X-Station-Sent-From: eve.bellcore.com
> Message-Id: <9604051430.AB03977@eve>
> X-Sender: [email-masked]
> X-Mailer: Windows Eudora Version 2.1.1
> Mime-Version: 1.0
> Content-Type: text/plain; charset="us-ascii"
> To: [email-masked] (Shannon Nix), [email-masked], [email-masked]
> From: Kaj Tesink <[email-masked]>
> Subject: review of draft-ietf-dlswmib-mib-07.txt
> Cc: [email-masked], [email-masked]
> 
> Hi all,
> 
> Here is finally my review of draft-ietf-dlswmib-mib-07.txt
> Sorry for the long delay.
> 
> In general I think this MIB is very good quality.
> There are a number of tidbits though. The more
> significant ones include the timestamp issue (item 16)
> and your Counter32 construct (item 14a).
> 
> Kaj
> ------------------------------------------------------------------
> 
> 1 - Section 2
> Align with newer SNMP RFCs (19xx series). See
> for an example kzm's revision of RFC1573.
> 
> 2 - Global typo IfIndex --> ifIndex
> 
> 3 - Section 3.2
> Fix the "work in progress" remark.
> Its either done, or if not talk only about the things that
> can be referred to.
> 
> 4 - Sect. 3.3 2nd bullet
> Unclear what is implied with "most implementations".
> - The DESCRIPTION clauses should say unambiguously
>   what must be created when.
> - The conformance clauses should state by whom.
> 
> 5 - Sect. 3.4.1
> Useful to include "[1]" after "Version"?
> Also the english  in the 4th object maybe
> ambiguous/unclear in "retrieving inorder the entries.."
> must be "ordered retrieval of the entries.."?
> 
> 6 - Sect. 3.5.1
> Despite the example the sentence "Thus, duplication.."
> is still unclear to me.
> 
> 7 - Sect. 3.5.3.6 4th line
> The sentence "For implementations.." should be fixed
> for similar reasons as item 4 above:
> - unclear what implementations are referred to
> - the conformance clause claims that all systems must
>   support these objects
> 
> 8 - 3.5.3.10
> Who are "our"?
> 
> 9 - Sect. 3.5.3.12 8th line
> "there should be.." shoould be "the agent must create.."?
> 
> 10 - 3.5.3.10
> Similar as in item 11 above:
> - try to avoid options or second guessing
> - say in DESCRIPTION and conformance clauses who
>   must keep what and when
> 
> 11 - Section 3.5 general comment
> This section is clearly very useful guidance!
> It gives many clues for implementors. Please
> make sure that these clues are also covered
> in the DESCRIPTION clauses.
> 
> 12 - p.14
> all the "|t" are typos?
> 
> 13 - p.16 key assumption 1
> Looks like a limitation - is this necessary?
> E.g., the entity mib may help you?
> Also the wording is ambiguous. e.g., does
> this mean 1 agent per 1 node?
> 
> 14a - p.16 Note 1
> This structure somewhat fuzzy to me.
> Judging from some objects where this is used:
> - the timeticks flagging the valid event
>   should always be used to make sure the sampling
>   interval is correct
> - if a value is unreliable before and reliable
>   after a certain time, you could consider to create a TC
>   with SYNTAX Gauge that restarts at 0 at each event
> - i noticed some Counter32 cases that use this structure
>   but where the counter instances do not even exist
>   before the event (e.g., p.40)
> 
> 14b - p.16 Note 2
> Would be better to flag in the DESCRIPTION
> of the trap definition how the trap generation 
> is controled.
> 
> 15 - p.18 1st line:
> Since this is just a syntax definition suggest to
> replace "alength of zero.." with "the address is a
> zero length string."
> 
> 16 - DlswTimeStamp
> This refers to dlswNodeUpTime?
> More importantly, why is this clock necessary and
> cant sysUpTime be used? Synchronization with multiple
> clocks tends not to save you headaches.
> This was raised in other MIBs as well. It seems to me that
> using sysUpTime only is sufficient for this MIB.
> 
> 17 - p.21 DisplayString
> The SIZE limitation is redundant.
> 
> 18 - p.22
> dlswNodeUpTime - as per 16
> 
> 19 - p.22 bottom object
> Redundant "can be found in"
> 
> 20 - p.25 ConfigIndex
> "managed station" --> "agent"
> This is a global comment. Avoid
> things like "Management station",
> "an implementation", "NMS" and talk
> in terms of "agent" and "manager". It
> tends to be more precise.
> 
> 21 - p.30 first DSECRIPTION
> Here are some examples of the point in
> item 20 above. Other examples in p.33
> first object, etc.
> 
> 22 - p.56 1st DESCRIPTION
> The last sentence is redundant and is
> also SNMP-version-specific. Suggest to
> remove it.
> 
> 23 - p.56 2nd DESCRIPTION
> As in 22 (and who are "we").
> 
> 24 - p.57
> As in 22 and 23
> 
> 25 - p.61 last object
> To which row is this pointer pointing?
> 
> 26 - p.88
> Update references [2], [4-6].
> 
> 
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> _/                                                                      _/
> _/  Kaj Tesink                                                          _/
> _/  Bellcore                                                            _/
> _/  - Broadband Data Services & Consulting  vmail (908) 758-5254        _/
> _/    331 Newman Springs Rd.                email [email-masked]   _/
> _/    Red Bank, NJ 07701                  faxmail (908) 758-4177        _/
> _/                                                                      _/
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>